Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

mypy_primer results

scikit-build-core (https://github.com/scikit-build/scikit-build-core)
+ src/scikit_build_core/_logging.py:153:13: warning[unsupported-base] Unsupported class base with type `<class 'Mapping[str, Style]'> | <class 'Mapping[str, Divergent]'>`
- Found 41 diagnostics
+ Found 42 diagnostics

pandas-stubs (https://github.com/pandas-dev/pandas-stubs)
+ pandas-stubs/_typing.pyi:1209:16: warning[unused-ignore-comment] Unused blanket `type: ignore` directive
- Found 5511 diagnostics
+ Found 5512 diagnostics

No memory usage changes detected ✅

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

Unfortunately, it appears that non-determinism remains due to factors entirely different from those considered in this PR.
However, that doesn't mean I think these changes are useless (they appear to improve performance slightly in benchmarks of large projects).

Anyway, I'm marking this PR as ready for review.

I like the approach, but I don't think using an IndexMap is the solution.

Iterating over two HashMaps, each created by inserting the same elements in the same order, will yield the same iteration order when run on the same platform.

The issue we see with fix point is that it's no longer guaranteed that the elements are inserted in the same order. However, we'll have the exact same issue when using IndexMap because IndexMap's iteration order is defined by insertion order, which isn't guaranteed to be deterministic within a cyclic query.

I'm not sure what the solution here is, other than applying some sort of sorting (somewhere?).

There's also one flaky diagnostic. What I suspect is that our convergence functions are now sensitive to which query is the outer-most cycle or some query that bails early as soon as it sees the first Divergent type (any type), and the any type is only visible depending on the cycle nesting

re: randomizing layouts: if you want to go down that route I suggest cribbing from rustc's -Zrandomize-layout which lets you pass the seed in as a CLI argument (and print the seed any time one is selected so people can try to reproduce an issue).

I think I'm leaning towards changing the hash maps in separate PRs and more explicitly talk about why the changes are necessary. I'm not convinced that it's necessary to use FxIndexMap in many cases.

I changed this PR to just replace FxHash{Map, Set} with new APIs. Therefore, this PR does not change any of the behavior of ty. Changes that affect behavior will be made after this PR (with reconsideration).

The purpose of this PR is to make developers aware that using FxHash{Map, Set} as an iterator is inherently unstable, and in a sense, it intentionally introduces noisy APIs.
However, if you feel it's troublesome to continue using unstable_iter() in places where it is clearly OK to use it as an iterator, one option is to give FxHash{Map, Set} a tag type and change its behavior depending on the tag. In this case, there is no need to prepare two types of structs.

use std::collections::HashMap;
use std::collections::hash_map::IntoIter;

/// You are sure you can always use this hash map/set as an iterator.
#[derive(Default)]
pub struct ImplIntoIterator;
#[derive(Default)]
pub struct NoIntoIterator;

#[derive(Default)]
pub struct FxHashMap<K, V, Tag=NoIntoIterator>(HashMap<K, V>, std::marker::PhantomData<Tag>);

impl<K, V> IntoIterator for FxHashMap<K, V, ImplIntoIterator> {
    type Item = (K, V);
    type IntoIter = IntoIter<K, V>;

    fn into_iter(self) -> IntoIter<K, V> {
        self.0.into_iter()
    }
}

fn main() {
    let map1: FxHashMap<u32, u32> = FxHashMap::default();
    let map2: FxHashMap<u32, u32, ImplIntoIterator> = FxHashMap::default();
    
    for _i in map1 {} // ERR
    for _i in map2 {} // OK
}

Using FxHashMap<K, V, ImplIntoIterator> means that you are declaring that it can always be used as an iterator and there is no problem with that, and using FxHashMap<K, V, NoIntoIterator> means that you need to make sure it is OK to use before each iteration (if it is safe you can use unstable_iter()).